WRM Trigger API

To get support from our team and view the status of the APIs, view our Support page.

What is the purpose of the WRM Trigger API?

The WRM Trigger API allows Work Suppliers to initiate actions in the test environment that are restricted to the role of a Work Requestor in the production environment. This enables a Work Supplier to complete testing of their work request management application independently.

How do I get access to meaningful test data?

To support use of the test environment, all Work Suppliers are be provided with a test playbook. The playbook contains data specific to the Work Supplier and work type, as well as details of how to use it to cover off various test scenarios.

What happens if Chorus releases a new version of the API or new functionality?

Any new versions of the WRM Trigger API are to be made available to Work Suppliers with sufficient lead time for implementation. You can then validate your integration, without being dependent on additional Chorus involvement.

Can I still use the WRM Trigger API while Chorus is BAT testing or during a Chorus deployment?

Yes. The only times the WRM Trigger API is unavailable are for planned updates and you will be notified of these ahead of time.

How closely aligned is the WRM Trigger API with the Work Request Manager API?

The WRM Trigger API sends requests through to the WRM API on behalf of the Work Supplier acting as the Work Requestor, so by necessity is closely aligned to the WRM API.

Do I need to complete a test end to end to maintain the Work Request state?

No, the state of a Work Request is maintained throughout its lifecycle. The task state reflects the operations that have already been performed on the Work Request.